-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Vulnerabilities and license checks #184
Conversation
Creates two checks: - A check with vulnerabilities added. If the check fails, it adds to the check the list of vulnerabilities found grouped by manifest. The check fails if vulnerables packages are added. - License check. A license check is created and it lists on the detail incompatible licenses (if any) and the unknown licenses. The check fails if there are incompatible licenses and succeeds otherwise Checks names are configurable. A breaking change was introduced, the action no longer fails if there are vulnerabilities or license violations. fail-on-violation parameter can be set to true to maintain backward compatibility.
@tspascoal I love the idea of having one check per feature, but the main Action one should never be green if one of the children checks fails. Can we overcome this? If not I don't think we should be spending extra cycles here (it's backwards incompatible and adds extra write security permissions). |
@febuiles Not failing the action, allows extra flexibility since users can fine grain when the PR can't be merged by requiring the checks them want (one of them or both). Backward compatibility (failing the action if one of the checks fails) can be achieved by explicitly setting the parameter This allows both the extra flexibility or getting the previous behavior with this parameter. So getting the old behavior by default, is a matter of changing the default value for |
In order for this to be backwards compatible I'd expect it to behave the same way that it has without the user having to modify their YAML. Remember that we pin all release to I don't know how the child checks work, could we default |
Yeah, my intention was to make it a V3, I've added a
If you feel that this should be a V2 release, we can certainly make Let me know which scenario you want to achieve:
|
I keep forgetting about auth, thanks for bringing it up! We can wait until we have the new config file format before revisiting this. |
The latest release of the action ( |
New Feature
Creates two checks:
By separating the failure in two, users can now control if license or vulnerabilities individually prevent the merge from happening.
Checks names are configurable.
Breaking Changes
A breaking change was introduced, the action no longer fails if there are vulnerabilities or license violations.
fail-on-violation
parameter can be set to true (default value is false) to maintain backward compatibility.There is another potential breaking change, since the workflow now requires
checks: write
permission, might need to add the new permission explicitly. The dependency review starter workflow will also have to be updated to add this permission